home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000139_news@newsmaster….columbia.edu _Wed May 27 12:10:45 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  7KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA13256
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 27 May 1998 12:10:44 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA11150
  7.     for kermit.misc@watsun; Wed, 27 May 1998 12:10:44 -0400 (EDT)
  8. Path: news.columbia.edu!newsfeed.nyu.edu!news.idt.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!europa.clark.net!128.158.254.10!news.msfc.nasa.gov!info.usuhs.mil!news.monroe.army.mil!wrdiss1.robins.af.mil!wpdiss1.wpafb.af.mil!oodiss1.hill.af.mil!news.cc.utah.edu!not-for-mail
  9. From: kirkland@ee.utah.edu (Dan Kirkland)
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 27 May 1998 08:55:57 -0600
  13. Organization: Univ of Utah Electrical Engineering Dept
  14. Lines: 141
  15. Message-ID: <6kh9ht$14i@ee.utah.edu>
  16. References: <6k42pd$a3m$1@apakabar.cc.columbia.edu> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu>
  17. NNTP-Posting-Host: ee.utah.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8802 comp.sys.hp48:81500
  19.  
  20. Sorry for joining this a bit late, but I don't read news real
  21. often.  And the university's news feed seems to be screwy, so
  22. many articles are very late (so my replies may be out of order).
  23.  
  24.  
  25. [very many deletions]
  26.  
  27. In article <6k4ef6$g6p$1@apakabar.cc.columbia.edu>,
  28.  fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  29. >In article <wk67iy1b8j.fsf@jhuapl.edu>,
  30. >Skip Collins  <collibf1@jhuapl.edu> wrote:
  31. >: fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  32. >: > But we usually find that what works for us fails to work for others, or
  33. >: > vice versa.  No doubt because there are many and varied HP-48 models, ROM
  34. >: > versions, etc etc.
  35.  
  36.  
  37. >: >  2. Should the flow control setting be NONE or XON/XOFF?  We have
  38. >: >     conflicting reports (see above).  Obviously the HP-48 *should* be
  39. >: >     exercising some form of flow control, but some reports indicate that
  40. >: >     it does not (even if it is set to do so).
  41. >: 
  42. >: Why is flow control necessary or even desirable given the maximum
  43. >: packet size is 94 and the receive buffer is 255?
  44. >: 
  45. >Theoretically, it would not be necessary.  But I don't know how their
  46. >Kermit implementation works internally.  Does it parse incoming packets as
  47. >it reads them, or does it read them first and then parse them?  Can anything
  48. >else happen during a read?  Garbage collection, etc?
  49.  
  50.  
  51. Flow control is dependant on BOTH sides, is it not?
  52. The HP48 should not need flow control for itself, but it sometimes
  53. may be needed to work with the OTHER computer (right?).
  54.  
  55. I have never used XON/XOFF with MSKERMIT or C-Kermit on HP-UX.
  56.  
  57. Someone did tell me that they needed XON/XOFF for transfers with
  58. C-Kermit on a PC with Linux. (???)
  59.  
  60.  
  61. >: >  3. Is the link transparent to incoming control characters?  Can the
  62. >: >     client Kermit program use control-character unprefixing when sending
  63. >: >     to the HP-48?  If not, the client program must be told to
  64. >: >     SET CONTROL PREFIX ALL prior to sending files to the HP-48.
  65. >: 
  66. >: Shouldn't control char unprefixing be a negotiated feature?
  67. >:
  68. >It would seem so, but no.  The reason is that the two parties have no idea
  69. >what lies between them, and so there is no way they can negotiate a safe
  70. >set of control characters.
  71. >
  72. >: If it is not, I can see where this might be the cause of many people's
  73. >: problems. Surely it is not the default?
  74. >:
  75. >Most Kermit programs prefix all control characters by default when sending a
  76. >file.  Kermit 95 is the exception, since most Windows 95 users demand "high
  77. >performance".  Kermit 95's default is to unprefix a fairly safe subset of
  78. >control characters.
  79.  
  80.  
  81. Sadly, the HP48 REQUIRES control character prefixing.
  82. All characters less than character 32, characters 127 to 159, and
  83. character 255, ALL MUST BE PREFIXED!
  84.  
  85. If ANY of these characters (0-31, 127-159, 255) are NOT prefixed,
  86. it just will NOT work!  (Sad huh?)
  87.  
  88.  
  89. >: > The HP communication port is half duplex, meaning that data can go in both
  90. >: > directions, but only in one direction at a time.  Therefore sliding
  91. >: > windows can not be used (this too should be negotiated automatically).
  92. >: 
  93. >: The serial port is full duplex. The infrared port is only half-duplex
  94. >: because of optical feedback.
  95. >:
  96. >Does this apply to all models?  I got my information about dead periods in
  97. >the serial port from an HP engineer, circa 1990.
  98.  
  99.  
  100. The HP48 kermit commands are designed to work with half-duplex.
  101.  
  102. Dead periods???
  103. The poorly written HP48 commands will surely CREATE dead periods
  104. such as between packet receiving and acknowledgement (and likely
  105. others...).
  106.  
  107.  
  108. >: > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
  109. >: > "parses" incoming text-mode material on the fly, and appends the material
  110. >: > from each incoming packet to a "string", resulting in a steadily
  111. >: > deteriorating transfer rate, at least up to some point at which the HP-48
  112. >: > dumps the string to storage and starts over with a new string.  There's 
  113. >: > not much that the Kermit client can do about that.
  114. >: 
  115. >: This is the biggest problem with hp48 kermit.
  116. >: 
  117. >Can you help clear this up?  What is the deal?  Text-mode transfers into
  118. >the HP-48 are the ones that get progressively slower?  But binary-mode
  119. >transfers into the HP-48 are OK?
  120.  
  121.  
  122. Okay, yes text-mode material is parsed on-the-fly.
  123.  
  124. But, ALL HP48 kermit transfers get progressively slower!
  125. That right!  BOTH text AND binary transfers get slower and slower!
  126.  
  127.  
  128. >Is it true that incoming text-mode packets are parsed as HP-48 programs?
  129. >So this means that only HP-48 programs may be sent in text mode, and any
  130. >other text files sent to the HP-48 are likely to be rejected.  One user
  131. >reported that any text file containing a "-" character would be rejected
  132. >for "Invalid syntax".
  133. >
  134. >This means that non-HP-48-program files must be sent to the HP-48 in binary
  135. >mode, right?
  136.  
  137.  
  138. No, this is not quite right.
  139.  
  140. Yes text-mode packets are parsed..., into a HP48 user OBJECT!!!
  141. It could be parsed into a program, or a list, or a string, or ...
  142.  
  143. For non-HP48 objects you just need to add a string header (C$ $ )
  144. before sending and it will be parsed into a string.
  145.  
  146.  
  147. One more thing...
  148.  
  149. It seems to me that ASCII mode on the HP48 is an HP48 mode and
  150. NOT a kermit mode! (???)
  151.  
  152. Meaning files can pretty much always be sent to the HP48 as binary
  153. files, then the HP48 will decide how to decode the file.
  154.  
  155. (It seems that the HP48 always sends starting with an F packet,
  156. and when it receives it expects to start with either an F or an
  157. X packet...???  Okay, I'm lost here...)
  158.  
  159. Hope this helps,
  160. dan